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CHARGING IN TELECOMMUNICATIONS NETWORK 
FIELD OF THE INVENTION 

The present invention relates generally to charging in a telecom- 
5 munications network. 

BACKGROUND OF THE INVENTION 

A third generation mobile communications system is in Europe 
named UMTS (Universal Mobile Telecommunications System). It is a part of 

10 the International Telecommunications Union's IMT-2000 system. UMTS/IMT- 
2000 is a global wireless multimedia system, which provides higher trans- 
mission speed (2 Mbit/s) than the existing mobile networks. 

UMTS and the General Packet Radio Service (GPRS) in the Global 
System for Mobile Communications (GSM) have been developed to provide 

15 wireless communications services packet-switched as well as circuit- 
switched environments. 

FIG. 1a shows with a greatly simplified diagram the UMTS network. 
Only those network elements that are significant in view of the actual inven- 
tion are shown. Of course, the network may contain one or more of each 

20 network element described in the following, depending on the capacity of the 
element, the number of mobile subscribers, and the organization of the net- 
work. 

The user terminals 100 may be multi-mode terminals, which can 
operate using at least two radio access technologies, such as UMTS and 
25 GSM, for example. 

A Gateway GPRS Support Node (GGSN) 102 is a gateway to ex- 
ternal networks, and it acts as a router, routing data packets to and from the 
GPRS support node currently serving the given GPRS terminal. 

A Serving GPRS Support Node (SGSN) 101 is at the same hierar- 
30 chical level as the mobile switching center MSC. It maintains information 
about the GPRS terminal's location inside its service area and performs se- 
curity and user access control functions. During data transfer the serving 
GPRS support node sends and receives data packets to and from the given 
terminal via a base station subsystem. The serving GPRS support node re- 
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quests routing information and subscriber information from the Home Loca- 
tion Register (HLR) 103, where all subscriber information is permanently 
stored. 

A UMTS specification allows a network subscriber to have one or 
5 more packet data protocol (PDP) addresses. Each of the addresses is de- 
scribed by one or more packet data protocol contexts in the user terminal, 
the serving GPRS support node, and the gateway GPRS support node. The 
packet data protocol context can be selectively and independently activated, 
modified and deactivated. All packet data protocol contexts of a subscriber 
10 are associated with the same Mobility Management (MM) context for the In- 
ternational Mobile Subscriber Identity (IMSI) of that subscriber. When the 
packet data protocol is set up, this means that a communication channel is 
set up. 

In FIG. 1a the serving GPRS support node and the gateway GPRS 

15 support node are located in the same domain A. When a connection is to be 
set up between a subscriber and the Internet 108, for example, the first step 
is that a mobile terminal 100 sends an active packet data protocol context 
request through a radio access network (RAN) 106 to the serving GPRS 
support node 101. The message includes a variety of parameters, which fur- 

20 ther include a packet data protocol address and an Access Point Name 
(APN). The access point name is a logical name referring to the gateway 
GPRS support node to be used. Here the access point name refers to the 
gateway GPRS support node 102, through which the data packets are 
routed between the mobile terminal and the Internet. Several messages are 

25 sent between the said network elements before the connection is completed. 

Event (Call/session) detailed data collection is always used when 
specified detailed information on an event (call/session) is required for billing 
or for the monitoring of event (call/session) details. Thus, each of the net- 
work elements collects data pertaining to each call/session until a certain 

30 predefined limit has been reached. The limit is a certain amount of data, time 
or other definable trigger values, such as a megabyte, for example. Then the 
network element generates an event detail record and sends it using an ac- 
tive protocol through the IP-network (Internet Protocol network) 107 to a 
Charging Gateway Function CGF1 104. In general, at least the following 

35 network elements generate event call detail records: the serving GPRS sup- 
port node, the gateway GPRS support node, the call state control function 
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(CSCF), and the Application Server(s) in radio access networks, such as a 
General Packet Radio Service (GERAN) or a UMTS Terrestrial Radio Access 
Network (UTRAN), the latter being a wideband multiple access radio network 
currently specified in the 3GPP (Third Generation Partnership Project). Nor- 
5 mally, during one session each of the said network elements generates a 
number of event call detail records relating to the session. 

The charging gateway function receives, for example, four event 
detail records pertaining to the same session from the serving GPRS support 
node and four from the gateway GPRS support node and then combines 

10 them with the help of a sequence number found in each event detail record. 
A formatted event call detail record is sent from the charging gateway func- 
tion to a Billing Center (BC) 105 for processing. 

A number of problems arise if the method described above is used 
as such in the latest release of the third generation mobile communications 

15 system. Some of the problems are briefly described with reference to FIG. 1b 
in the following. 

Several millions event detail records are constantly generated in 
each of the network elements, such as the serving GPRS support node 101, 
the gateway GPRS support node 102, the call state control function CSCF 

20 109, the application server 110, or some other network element N 111. Then 
each of the network elements independently passes the call detail records to 
a charging gateway function CGF1 - CGFN 112. The problem is that at the 
moment there is no mechanism which would automatically in real-time cen- 
tralize directly all the event detail records pertaining to one session for the 

25 specified charging gateway function (e.g. CGF1) in the network/domain con- 
cerned. By contrast, the event detail records are directed to a large number 
of different charging gateway functions. This leads to the problem of how to 
combine those event detail records pertaining to the same session/call. One 
solution is to use a standalone device, a so-called mediator, for collecting 

30 and combining the event detail records before sending them for further proc- 
essing to the billing center 106. Combining the event detail records in the 
mediator is quite complicated and time-consuming. 

One solution is to use a unique session identifier for combining the 
right event detail records. This kind of solution is described in the applicant's 

35 earlier US patent application 09/577,152, which has not been published by 
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the filing date of the present application. The identifier is called a global 
transaction ID (unique session identifier.) 

However, that solution does not solve the time-consuming problem 
above, i.e. different network elements still send event detail records to differ- 
5 ent charging gateway functions. 

SUMMARY OF THE INVENTION 

The present invention relates generally to event detail record 
(EDRs) collection and management (related to charging, monitoring, lawful 
interception etc.) in a telecommunications network and specifically to post- 
10 paid and event detail records based pre-paid charging in a third generation 
mobile communications network. 

The objective of the invention is to provide a solution whereby 
event detail records relating to one session but generated by a number of 
different network entities are sent in a centralized manner in real-time to a 
15 given collecting network entity. Thus, the event data combination is opti- 
mized and the unnecessary transmission of event detail records from one 
collecting network entity to another is avoided. The objective is achieved 
through a method and system characterized by what is stated in the inde- 
pendent claims. 

20 The idea of the invention is to collect session-specific data in a 

given collecting etwork entity when user connections during a session are 
connected through a number of network entities generating event detail re- 
cords and having mutual signaling connection. 

Each of the network entities generating event detail records in a 

25 domain/network has a corresponding table including a set addresses of net- 
work entities collecting event detail records. The collecting network entity ad- 
dress is universally unique. 

During connection set up a network entity which receives a connec- 
tion/session establishment request selects an address for the collecting net- 

30 work entity from the said table and proposes that address to the network en- 
tities generating event detail records by inserting the address with a unique 
session identifier to a signaling message to be sent to the next network entity 
which generates event detail records. 
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When the network entity that generates event detail records re- 
ceives the proposed address, it checks whether the address is configured in 
the table of collecting network entities. 

If the proposed address matches a primary address of the collect- 
5 ing network entity in the configured table, the network entity sends the mes- 
sage further to the next network entity. 

If the proposed address does not match the primary address of the 
collecting network entity in the configured table, the network entity checks 
whether the next address on the table matches and so on. If the address is 
1 0 found, the message is sent to the next network entity as above. 

If the proposed address is not found in the table, the said network 
entity chooses the primary collecting network entity address from the table, 
replaces the proposed address with it, and sends the message to the next 
network entity. 

15 In cases where the proposed collecting network entity is not in use 

or does not respond, the network entity in question replaces the proposed 
address by the next address from the configured table and sends the mes- 
sage to the next network entity. 

All event detail records pertaining to the session/call in question are 

20 sent in real-time during the session/call to the same collecting network entity 
address thus selected. 

The combining of the event detail records relating to the session is 
performed using the unique session identifier in this specified collecting net- 
work entity. 

25 Thus, event detail records generated from several network entities 

related to one session/call are centralized in the same collectin g network en- 
tity. This speeds up the actual combining of the event detail records. 

The solution is dynamic and simplifies the transmission of the event 
detail records in the network regardless of whether the network entities are in 

30 the same or different networks/domains. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is described more closely with reference to the ac- 
companying drawings, in which 
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FIG. 1a illustrates with a simplified diagram a third generation mobile 
communications system; 

FIG. 1b depicts a prior art solution for sending call detail records in a tele- 
communications network; 
5 FIG. 2 shows as a block diagram an example of the implementation of 
the method according to the invention; 

FIG. 3 is a signaling chart showing an example of a basic connection 
setup; 

FIG. 4 illustrates a charging gateway address transmission in one do- 
10 main in the third generation mobile communications network; 

FIG. 5 illustrates a charging gateway address transmission in one do- 
main in the third generation mobile communications network; 

FIG. 6 illustrates a charging gateway address transmission in two do- 
mains in the third generation mobile communications network. 

15 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
In the following, a dynamic real-time event detail record collection 
and management in a third generation mobile communications system or a 
All IP (3GPP rel.5) network is described. However, it is understood that the 
20 invention is not restricted to UMTS all-IP networks but can also be imple- 
mented in any kind of network where there is a need to use a dynamic real- 
time event detail record collection and management. 

The idea of the method described in the following is to concentrate 
the transmission of event detail records produced in different network ele- 
25 ments in a telecommunications network in a specified collecting network en- 
tity. 

Hereafter the event detailed records will also be termed EDR, the 
serving GPRS support node termed SGSN, the gateway GPRS support 
node termed GGSN, the charging gateway function termed CGF, the appli- 
30 cation server termed AS, and the call state control function will be termed ei- 
ther CSCF or CPS (call processing server). 

The invention is now described in detail with some examples refer- 
ring to FIG. 2-6. The event data is charging data and the network entities 
are network elements in the following examples. 
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FIG. 2 illustrates one way of implementing the functionality required 
to increase the efficiency of charging. 

To overcome the problem of time-consuming charging data combi- 
nation and the irrelevant transmission of event detail records between differ- 
5 ent charging gateway functions, each network element in the do- 
main/network sends the EDRs related to one session/call to the same CGF. 
Thus, the network elements SGSN 201, the GGSN 202, the application 
server 203, and the CPS 204 transmit all EDRs via a Ga interface in the 
UMTS all-IP network to the CGF 205. 

10 It is important to note that this is just a very simplified example. 

Globally the UMTS network comprises several network elements, each of 
which is continually producing millions of event detail records. 

In FIG. 3 a voice call set up is considered as an example. A signal- 
ing diagram shows the basic connection setup in the 3GPP rel.5 network. 

15 The signaling messages mentioned here are just examples, and there can 
also be many other kinds of signaling messages. This example indicates only 
one of the possible ways of transferring the CGF address between network 
elements exchanging signaling messages pertaining to the call/session. Al- 
ternatively, the user terminal could also be involved in the process of trans- 

20 ferring the unique session identifier and the CGF address. 

The call set-up signaling is symmetric between the calling sub- 
scriber and the application server, on the one hand, and between the appli- 
cation server and the called subscriber, on the other. Therefore, it is enough 
to examine only one side of the signaling chart. 

25 It is assumed that the packet data protocol PDP context has been 

activated. As already stated above, each packet data protocol context can be 
selectively and independently activated, modified, and deactivated. 

A calling party, mobile subscriber A, wants to make a voice call to a 
called party, who in this particular example may be another mobile sub- 

30 scriber B. In spite of the voice call, the connection can also be a session, i.e. 
from the subscriber to a video server, or a network game, etc., depending on 
the user terminal and service providers. 

The user terminal sends via the serving radio access network RAN, 
the SGSN, and the GGSN, an INVITE message 300 to a call state control 

35 function CSCF or more accurately to a proxy call state control function P- 
CSCF. 
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The call state control function CSCF can be divided into two logical 
parts, i.e. the CSCF can act as the proxy CSCF or a serving CSCF (S- 
CSCF). The CSCF handles several functionalities such as: acting as a first 
entry point and performs the routing of incoming calls; it reports call events 
5 for billing, auditing, intercepting, or other purposes; it may provide a server 
trigger mechanism; it receives and processes application level registration; it 
notifies the home domain of the initial user's access (e.g. the CSCF signaling 
transport address and the user ID). 

The P-CSCF is a first contact point for the user terminal within the 

10 Internet protocol multimedia subsystem (IMS). Every user terminal always 
has a proxy CSCF associated with it and located in the same network. 

The INVITE message 300 is a request "I want to establish a voice 
call connection to subscriber B". In response to the received message, the 
proxy CSCF generates a unique Call-ID, identifies from a configured list a 

15 charging gateway to be used as a primary charging gateway into which all 
EDRs generated during the call are sent, stage 301. These two unique 
parameters are stored into a memory, and the parameters are also added to 
the received message. The Call-ID is available for IP Multimedia Core Net- 
work Subsystem (IMS) EDRs. 

20 From now on the said charging gateway is to be called by the name 

of proposed charging gateway function, proposed CGF, or proposed IPv6 
CGF address (IPv6 = Internet Protocol version 6). 

At stage 302 the P-CSCF sends a SIP INVITE message, including 
the Call-ID and the IPv6 address of the proposed charging gateway, to the 

25 serving CSCF (S-CSCF) where the call/session states are handled. Then the 
P-CSCF starts to establish the call connection. The Call-ID is available for 
IMS EDRs. 

The session initiation protocol SIP is an application level signaling 
protocol used for establishing sessions in an IP network. A session can be a 
30 simple two-way telephone call or a collaborative multimedia conference ses- 
sion. The SIP is a protocol for creating, modifying, and terminating sessions 
with one or more participants. It also supports user mobility and redirects 
requests to the user's current location. 

The S-CSCF analyzes the destination address and determines 
35 whether the subscriber is of the same or a different network operator. The S- 
CSCF also checks whether the proposed CGF address matches the primary 
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CGF address in the configured list of the CGF addresses. If the result of 
comparison is TRUE, i.e. the addresses are the same, all the EDRs pro- 
duced in the S-CSCF relating to this particular call will be transmitted to the 
proposed CGF address. The proposed CGF address is included in mes- 
5 sages between different network elements concerning this particular call in 
the beginning and during the call establishment phase. The checking of the 
proposed CGF address from the configured list of the CGF is repeated from 
now on by every network element receiving the messages pertaining to this 
call. 

10 If the proposed address does not match the primary address of the 

charging gateway function in the configured list, the network element 
chooses the next charging gateway function address from the list, replaces 
the proposed address with it, and sends the message along with the unique 
session identifier to the next network element. 

15 Also in cases where the proposed charging gateway function is not 

in use or does not respond, the network element in question replaces the 
proposed address with the next address from the configured list. 

Next, at stage 303 a SIP INVITE message along with the Call-ID 
and the IPv6 address of the proposed charging gateway is sent from the S- 

20 CSCF to an application server. The Call-ID is available for application server 
EDRs. The application server acknowledges the received message by send- 
ing the RESPONSE message 304 to the S-CSCF. 

In response the S-CSCF sends the SIP INVITE message 305 in- 
cluding the Call-ID and the IPv6 address of the proposed charging gateway 

25 to an interrogating CSCF (l-CSCF). The l-CSCF is the contact point within an 
operator's network for all connections destined to a subscriber of that net- 
work operator. The Call-ID is available for IMS EDRs. 

The first task is now to find out where the called subscriber is lo- 
cated and whether the subscriber's mobile terminal is free to take a voice 

30 call. 

When the location of the mobile terminal is made known and it is free 
to receive calls, the OK message 306 informing that the connection can be 
established is sent from a network element such as S-CSCF located in some 
other operator's network. The message is sent via the CSCF, the GGSN, 
35 and the SGSN to the user terminal of the subscriber A. 
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Thus far the messages between the above network elements have 
been transmitted through signaling channels, i.e. no traffic channel has been 
assigned yet. Messages on the lower part of the signaling chart are needed 
for media/traffic path establishment. 
5 At stage 307 the user terminal sends to the SGSN an Activate- 

SecondaryPDP_Context REQUEST message, and the SGSN forwards the 
CreatePDP-Context REQUEST message 308 to the GGSN. In response to 
the received message the GGSN generates a Charging-ID, which is avail- 
able for SGSN and GGSN EDRs. After that the GGSN sends the Authentica- 

10 tion REQUEST message 309 to the P-CSCF, which may be based on COPS 
(common open policy service protocol) messages, for example. 

The policy control function is a logical entity, and it controls which 
packets are allowed to pass through the GGSN. In response to the message 
the P-CSCF informs the GGSN of its decision on authorizing the PDP Context 

1 5 Activation by sending a DECISION message 31 0, including the Call-ID and the 
IPv6 address of the proposed charging gateway. This call-ID is available for 
PS EDRs. 

The next step is that the GGSN responds to the SGSN with a Cre- 
atePDP_Context RESPONSE message 311, including the call-ID, the Charg- 
20 ing-ID, and the IPv6 address of the proposed charging gateway. The Call-ID 
and the Charging-ID are available for PS EDRs. At stage 312 the SGSN 
sends an ActivateSecondaryPDP_Context ACCEPT message to the user 
terminal. 

All EDRs pertaining to this call are sent automatically from each of 
25 the network elements described above to the proposed CGF. 

In the following, the present invention is illustrated with three exam- 
ples in reference to FIG. 4-6. 

FIG. 4 illustrates a process of sending the unique charging gateway 
address to be used in one domain in the third generation mobile communica- 
30 tions system. The unique Call-ID is also transmitted along with the charging 
gateway address as described above. 

The numbering in FIG. 4 corresponds to the numbering in FIG. 1 so 
that the network elements and networks 100-108 correspond to the network 
elements and networks 400-408. Home Subscriber Services (HSS) register 
35 403 is enhanced with a Home Location Register (HLR). 
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The packet data protocol PDP context has been activated, i.e. the 
signaling channel is created between the user terminal 400 and the call state 
control function 409. The user terminal has requested connection establish- 
ment to a called subscriber. Alternatively, the subscriber of the user terminal 
5 might wish to connect to an application server that serves multimedia, video, 
games, etc. The signaling messages needed when the connection is set up 
are sent via the SGSN 401 and the GGSN 402 to the CSCF. The CSCF ana- 
lyzes the content of the received message, e.g. the call set up request, and 
performs actions such as forwarding the request to a CSCF located in an- 

10 other operator's network. It is shown in FIG. 4 that each of the network ele- 
ments, i.e. the SGSN 401, the GGSN 402 and the CSCF 409, has a config- 
ured list of charging gateway function address 410-412. The CSCF selects 
from the list 410 the charging gateway function address CGF1 to be used by 
all network elements involved in the session in question. The proposed 

15 charging gateway function address is sent along with the message to the 
GGSN, which in turn sends it along with the message to the SGSN. The 
message transmission and the checking of the proposed charging address 
are carried out as above. The lists in the network elements correspond to 
one another. 

20 FIG. 5 also illustrates a process of sending the unique charging 

gateway address in one domain in the third generation mobile communica- 
tions system. In the figure the packet data protocol PDP context has been 
activated between the user terminal and the application 500, and the 
connection between the user terminal and the application is set up and acti- 

25 vated. The CSCF informs the application in the message (described in FIG. 
3) of the proposed CGF to be used during the connection. Messages be- 
tween the CSCF and the application are sent at the application layer. 

FIG. 6 illustrates a process of sending the unique charging gateway 
address in two domains of the third generation network. 

30 Operator A owns the network in domain A, and operator B owns the 

network in domain B. The configured lists differ from each other in the net- 
work elements of different network owners. The CSCF 409 proposes the 
CGF5 address to the GGSN 402, but the GGSN does not find the proposed 
address from its own list. In this case the GGSN selects from its list a primary 

35 charging gateway function CGF1, replaces the CGF5 address with it, and 
forwards the message to the SGSN. 
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A subscriber may simultaneously have a number of active 
calls/sessions' such as a voice call, e-mail, a video session. With the help of 
the unique identifier, it is possible to trace in detail the charging information 
generated e.g. distinguish from the charging information as to how much 
5 data volume was transferred during the voice call, the e-mail, or the video 
session. 

By means of the unique session identifier along with the unique 
charging gateway address, which are sent from one network element to the 
next network element, it is possible to achieve fast, clear, and dynamic 

10 charging as well as activities relating to monitoring, collecting statistics, and 
lawful interception. 

Although the invention is designed to be especially suitable for the 
third generation mobile communications system, the invention is not limited 
to application for such system. It is clear that the described charging method 

15 and system can be installed in networks of any kind. Of course, also the user 
terminal can be of any kind. In addition, the unique session identifier and the 
CGF address can be delivered to the user terminal and then to the other 
network elements generating charging data in order to ensure that the 
unique session identifier and the CGF address are delivered to all those 

20 network elements involved in the session/call in question. 

Implementation and embodiments of the present invention have 
been explained above with different examples. However, it is understood that 
the invention is not restricted by the details of the embodiments above and 
that numerous changes and modifications can be made by those skilled in 

25 the art without departing from the characteristic features of the invention. The 
described embodiments are to be considered illustrative but not restrictive. 
Therefore the invention should be limited only by the attached claims. Thus, 
alternative implementations defined by the claims, as well as equivalent im- 
plementations, are included in the scope of the invention. 

30 
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What is claimed is: 
1 . A method for collecting session-specific event data in a network 
where user connections during a session are connected through a number of 
network entities generating event data and having a mutual signaling con- 
5 nection, 

characterized by the steps of 

storing in each of the network entities generating event data a set 
of addresses for the network entities collecting event data, 

during connection set-up 
1 0 choosing one address of a collecting network entity from the set in 

each of the event data generating a network entity, 

and during the connection 

sending event data which is being generated during the connec- 
tion to the network entity chosen. 
15 2. A method according to claim ^characterized in that the 

address of the collecting entity is globally unique. 

3. A method according to claim 1, characterized in that 
during the connection set-up a predetermined network entity receives a ses- 
sion/connection establishment request, selects the said address from the 

20 set, and indicates it to the other network entities generating event data by 
inserting the address in the signaling messages which it sends during the 
connection set-up. 

4. A method according to claim 3, characterized in that a 
globally unique identifier pertaining to the said session is inserted in the said 

25 message. 

5. A method according to claim 3 or 4, characterized by 
receiving a signaling message including the said address, 
comparing the said address with a primary address of the set, and 

if the addresses compared are equal, 
30 sending the message to the next network entity, whereby said re- 

ceiving and comparing steps are performed in the network entity which gen- 
erates event data. 

6. A method according to claim 3 or 4, characterized by 
receiving a signaling message including the said address, 

35 comparing the said address with a primary address in the set, and 

if the addresses compared fail to correspond to each other, 
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replacing the received address with the primary address selected 
from the set and sending the message to the next network entity, whereby 
said receiving and comparing steps are performed in the network entity 
which generates event data. 
5 7. A method according to claim 1, characterized in that the 

network entity is a network element. 

8. A method according to claim ^characterized in that the 
network entity is a user terminal. 

9. A method according to claim ^characterized in that the 
10 content of the set is identical at least in the network entities within the same 

domain. 

10. A method according to claim 1, characterized in that 
the content of the set is identical at least in the network entities within the 
same network. 

15 1 1 . A method according to claim 1, characterized in that 

the stored set of addresses of the network entities generating the event data 
is in the form of a table. 

12. A method according to claim 1, characterized in that 
the event data includes charging data. 
20 13. A communication system comprising at least the routing net- 

work entities and the network entities generating the event data and the net- 
work entities collecting the event data, 

characterized in that each of the event data generating 
network entities includes 
25 a set of addresses for the network entities collecting event data, 

selecting means for choosing from the set one address of a col- 
lecting network entity, 

signaling means for signaling selected addresses between net- 
work entities generating event data, 
30 sending means for sending event data generated during a session 

to the address chosen by the selection means. 
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